Subject: Boeing CPIC 2.0 security comments

From: "Hildebrand, Jeff" <[email-masked]>
Date: Tue, 09 Nov 93 17:00:00 PST

Enclosed are the Boeing comments on CPIC security.
Regards,
Jeff Hildebrand

Page 33, replace Note: when the CRM type is OSI TP, there is
no support for conversation security.

Replacement text:

The OSI CRM supports conversational security during
conversation startup and at user defined intervals during a
conversation.  The Generic Upper Layers Security standard
ISO/IEC 11586-1 specifies the protocol necessary to support
security between cooperating OSI TP systems.  The standard
supports authentication through simple userid/password,
encrypted (strong) userid/password, and security tickets.  The
standard also supports data protection through security data
transformations.  The current OSI TP CRM does not provide
session level security and assumes that the session is not secure.

Access information gained from either side information or the
SET_CONVERSATION_USER_ID and
SET_CONVERSATION_SECURITY_PASSWORD calls are
used in accordance with the session's application context.  An
application program is designed to use one or more application
contexts.  Application contexts can vary for many reasons, in
this case they specify different types of authentication and/or
security data transformation requirements.  It is possible to
contact two identical applications, each having different security
requirements.  For example, one uses simple passwords and
userids while the other uses security tickets and security data
transformations.  Security can be applied when a conversation is
allocated and when data is sent and received.

Authentication is accomplished when a conversation is allocated
by specifying to node services how it is to treat the userid and
password that were obtained from side information or the
SET_CONVERSATION_USER_ID and
SET_CONVERSATION_SECURITY_PASSWORD calls.
The application program, because it understands the application
context, can instruct node services what to do with the supplied
information, via the conversation_security_type parameter on
the SET_CONVERSATION_SECURITY_TYPE.

The conversation can be reauthenticated and security
transformations applied to user data during the conversation .
These functions can be done by the application program itself,
using locally defined mechanisms and interfaces, or by the U-
ASE in conjunction with the SESE ASE.  In either case, the
conversation's userid and password is maintained by Node
Services.

Page 193 Set_Conversation_Security_Password
Clause: security_password_length

Delete sentence: The length can be from 0 to 10 bytes.

Rationale: The length of the password should fit the user
environment.  For local SNA systems 10 character should be
enough.  OSI has a global view and tries to impose as few
constraints as possible, the 10 byte limit is sure to conflict with
how some users wish to use CPIC.

Page 195 Set_Conversation_Security_Type
Clause:conversation_security_type

Add the following values:

CM_SECURITY_PROGRAM_STRONG
The encrypted values of the security_user_ID and
security_password characteristics are used to set the
access security information included in the
conversation startup request.

CM_SECURITY_PROGRAM_TICKET
The values of the security_user_ID and
security_password characteristics and/or other local
characteristics are used to access the security ticket
mechanism and provide that ticket in the conversation
startup request.

Page 197 Set_Conversation_Security_User_ID
Clause: security_user_ID_length

Delete sentence: The length can be from 0 to 10 bytes.

Rationale: The length of the userid should fit the user
environment.  For local SNA systems 10 characters should be
enough.  OSI has a global view and tries to impose as few
constraints as possible, the 10 byte limit is sure to conflict with
how some users wish to use CPIC.